Guía de uso de la herramienta de pruebas de mutación en la Plataforma CI/CD

Funcionamiento de las pruebas de mutación

La ejecución de las pruebas de mutación consta de varios pasos: 
 

1. Generación de mutantes  

Se generan N mutantes. Cada mutante tiene UN único cambio, que altera un operador o condición (cambiar un + por -, quitar un if, cambiar > por >=). 

Cualquier parte del código cuya lógica pueda ser alterada por la herramienta de mutación para generar código artificial erróneo se considera un “punto de mutación”. De dicho punto de mutación salen tantos mutantes como mutaciones posibles tenga ese punto. Por ejemplo, para un punto de mutación de tipo aritmético, salen tres mutantes, ya que existen cuatro operaciones aritméticas (+, -, /, *).  

El número de mutantes es la suma de posibilidades de todos los puntos de mutación. Nótese que el número de mutantes generados es completamente independiente de la cantidad de pruebas unitarias existentes. Por lo general, el número de mutantes generados escala de manera lineal con el tamaño del código fuente (excluyendo las pruebas unitarias) 
 

2. Ejecución de pruebas unitarias para cada mutante

Para cada mutante, la herramienta lanza las pruebas unitarias, parando únicamente cuando el mutante muere (o sobrevive a todas las pruebas unitarias)

Las herramientas de mutación optimizan la ejecución de las pruebas. Por lo general, no lanzan pruebas unitarias para un mutante si detectan que dicho mutante no afecta a la ejecución de dicha prueba. 

Ejemplo práctico

A continuación, se expone un trozo de código incorrecto (el método add, resta en vez de sumar) y una prueba unitaria mal diseñada:

import static org.junit.jupiter.api.Assertions.assertTrue;
import org.junit.jupiter.api.Test;
 
class Calculator {
 int add(int a, int b) {
   return a - b;
 }
}
 
public class CalculatorTest {
 
 @Test
 void add_has_a_test_but_the_test_is_faulty_and_useless() {
   Calculator calc = new Calculator();
 
   int result = calc.add(2, 1); // With the bug, result is 1
 
   assertTrue(result == result);
 }
} 

Aunque la lógica del método es incorrecta (resta en lugar de sumar), la prueba unitaria asociada se ejecuta sin fallos. Esto ocurre porque la prueba únicamente comprueba que el resultado es igual a sí mismo, algo que siempre se cumple independientemente de la lógica implementada.  

Como consecuencia, el código se considera probado y genera cobertura, ya que la función se ejecuta, pero en realidad no se está validando su comportamiento. Este ejemplo muestra que tener cobertura de código no garantiza que las pruebas unitarias, por sí solas, sean fiables ni efectivas para detectar comportamientos no deseados. 

Anexo

A continuación, se muestra el listado de frameworks y herramientas permitidas, con sus versiones mínimas, para cada stack tecnológico.

NOTA Para El stack de Node no se permite el uso de navegadores dentro de Jest. Jenkins es incapaz de lanzar dichos navegadores (19/01/2026)